Certificate Pinning is a method of authenticating servers to clients based on prior knowledge of the identity of the server and provisioning (‘hardcoding’) its details into the client through a data item known as a ‘pin.’ Pinning is the process of associating a host with their expected X509 certificate or public key in order to counteract or block man-in-the-middle (MITM) attacks where an intermediary server intercepts and hijacks network sessions between a client and server using a false certificate. Using certificate pinning, once a certificate or public key is known or seen for a host, the certificate or public key is associated or ‘pinned’ to the host. This process leverages knowledge of the pre-existing relationship between the user and an organization or service. Certificate pinning thus lets a client know more about the certificate it will be expecting to receive from the server than the information exchanged during the connection handshake.
Present certificate pinning methods use information that is already known on the server or service, and therefore do not need to rely on generalized mechanisms meant to solve the key distribution problem. When the server is known beforehand, it is somewhat trivial to hardcode its fingerprint into clients that expect to connect to it, like browsers and mail clients. A user is given a reasonable expectation that if the connection is completed, then it is happening with the desired server and not an impersonator. Thus, if the server hostname is known beforehand and relatively constant, or if it is a well-known public location, then the certificate can be added when the client is developed and become a hardcoded part of it. Adding the certificate at development time is preferred since preloading the certificate or public key out of band usually means the attacker cannot taint the pin. If the certificate or public key is added upon first encounter, the system requires key continuity, which can fail if the attacker has a privileged position during the first connection. In most cases, as when a vendor develops a client/server system that will be deployed at a customer, this preloading is not possible simply because the developer has no knowledge of the certificate infra-structure at every possible customer. There needs to be a way to deliver the pin out-of-band, securely and in a trusted manner after deployment of the servers. Key continuity is not a solution, since it implies the first connection is somehow assumed trusted. In many networks, especially in the mobile environment, a packet can go through a number of uncontrolled networks, and this assumption of a secure first-connection is a weak one.
Present certificate pinning systems and methods are thus not absolutely effective in deployment environments where servers are sold to customers who provision them in their own networks. What is needed, therefore, is a method of providing a secure, trustable method of sharing the certificate pinning information after deployment, and to solve the dynamic key distribution problem in certificate pinning systems.
The subject matter discussed in the background section should not be assumed to be prior art merely as a result of its mention in the background section. Similarly, a problem mentioned in the background section or associated with the subject matter of the background section should not be assumed to have been previously recognized in the prior art. The subject matter in the background section merely represents different approaches, which in and of themselves may also be inventions.